JPXDecode: read the JP2 container and codestream header - #31

What

The first stage of JPXDecode, per ADR-005. It reads the container and the main header of a JPEG 2000 image:

• JP2: the signature box and the top-level box walk to the jp2c box (32-bit and 64-bit box lengths), or a raw J2K codestream that starts with SOC.
• SIZ: the image and tile sizes, and each component's depth, sign and subsampling.
• COD: the progression order, the layer count, the colour transform, the decomposition levels, the code-block size and whether the transform is the reversible 5/3 or the irreversible 9/7.

JpxDecoder.TryReadHeader states those values and refuses a container without a codestream, a main header without SIZ or COD, and a codestream whose fields are out of range.

Fixtures

OpenJPEG's, through Pillow, under tests/SharpCorePDF.Tests/Assets/jpx/: jpx-5-3.jp2 and jpx-9-7.jp2 for the two transforms and jpx-5-3.j2k for the raw form, each 32 x 32, three 8-bit components, five decomposition levels, no colour transform. The expected .bin files are Pillow's decode of the same files, kept for the pixel stage.

Not in this stage

The pixels: the packet headers and the tag trees, the EBCOT bit-plane passes with the MQ arithmetic decoder, the inverse 5/3 and 9/7 wavelets, and the reversible/irreversible colour transform. ADR-005's JPX acceptance is a bit-exact reversible decode, so this is a draft: merging it alone would add a tested foundation that no production path calls yet.

Validation

• dotnet build SharpCorePDF.slnx -c Release: 0 warnings, 0 errors
• JpxDecoderTests: 6/6
• Full suite: 1272/1272 on net10.0 and net11.0
• ADR-005: the JPX status is "in progress — the JP2 container and the codestream header are read; the packets and the inverse wavelet are next"